build.sh: allow group write on /usr/* #4410
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Code Review
This pull request adds group-write permissions to /usr/bin to facilitate testing in a CI environment. However, this change introduces a critical security vulnerability by allowing any process with root group privileges to modify system binaries, potentially leading to privilege escalation. My review includes a critical comment explaining the risks and suggesting a safer alternative, such as using a separate directory for test binaries and modifying the PATH.
build.sh
Outdated
Comment on lines
115
to
120
| # Allow group write permissions on /usr/bin because in upstream | ||
| # project's CI we want to overwrite binaries for testing. The dir is | ||
| # owned by root:root and CI runs in openshift as a user that is a | ||
| # member of the `root` (GID: 0) group. | ||
| # See https://github.com/coreos/coreos-installer/pull/1716 | ||
| chmod g+w /usr/bin |
Contributor
There was a problem hiding this comment.
Granting group-write permissions to /usr/bin introduces a critical security vulnerability. Any process running with GID 0 (as is common in OpenShift for non-root users) can modify or replace any system binary in that directory. This could be exploited for privilege escalation if a compromised process replaces a commonly used executable (like ls, sudo, or curl) with a malicious version.
While this is for a CI environment, it's a dangerous practice that violates the principle of least privilege. A safer alternative for overriding binaries for testing would be:
- Create a separate directory (e.g.,
/opt/testing-bin). - Grant write permissions to that directory.
- In your CI test environment, prepend this directory to the
PATHenvironment variable (e.g.,export PATH=/opt/testing-bin:$PATH).
This approach allows you to override binaries without altering the permissions of critical system directories.
dustymabe
added a commit
to dustymabe/coreos-installer
that referenced
this pull request
Jan 9, 2026
We opened up the permissions when building the COSA container [1] so this isn't necessary any longer with a few adjustments here. [1] coreos/coreos-assembler#4410
Member
Author
|
so here we are opening up permissions on @HuijingHei maybe we could be more targeted in what we copy over in ostree CI? What we're currently copying is quite exhaustive: Details |
dustymabe
added a commit
to dustymabe/coreos-installer
that referenced
this pull request
Jan 9, 2026
We opened up the permissions when building the COSA container [1] so this isn't necessary any longer with a few adjustments here. [1] coreos/coreos-assembler#4410
dustymabe
added a commit
to dustymabe/coreos-installer
that referenced
this pull request
Jan 9, 2026
We opened up the permissions when building the COSA container [1] so this isn't necessary any longer with a few adjustments here. [1] coreos/coreos-assembler#4410
Member
Agree with you, I have no better workaround for this, how about |
Member
Author
|
@travier WDYT? |
travier
reviewed
Jan 15, 2026
build.sh
Outdated
| # owned by root:root and CI runs in openshift as a user that is a | ||
| # member of the `root` (GID: 0) group. | ||
| # See https://github.com/coreos/coreos-installer/pull/1716 | ||
| chmod g+w /usr/bin |
Member
There was a problem hiding this comment.
Maybe:
Suggested change
| chmod g+w /usr/bin | |
| chmod -R g+w /usr/bin |
?
Member
There was a problem hiding this comment.
For coreos-installer, /usr/bin is enough, but for ostree, maybe need more like /usr/lib{,64} or /usr/share?
dustymabe
added a commit
to dustymabe/ostree
that referenced
this pull request
Jan 16, 2026
With some changes made upstream to COSA [1] we shouldn't need to runAsUser: 0 any longer. [1] coreos/coreos-assembler#4410
dustymabe
changed the title
dustymabe
force-pushed
the
dusty-open-perms
branch
from
a76a5d1 to
b0f5abb
Compare
Allow group write permissions on /usr/ because in upstream project's CI we want to overwrite software for testing. The directories are typically owned by root:root and CI runs in openshift as a user that is a member of the `root` (GID: 0) group. See coreos/coreos-installer#1716 Also add an exception for /etc/grub.d for OSTree upstream CI.
dustymabe
force-pushed
the
dusty-open-perms
branch
from
b0f5abb to
59fb249
Compare
Member
Author
|
ok. I think I've covered all the corner cases now and tested in coreos/coreos-installer#1716 and ostreedev/ostree#3562 |
HuijingHei
approved these changes
Jan 16, 2026
Member
|
/retest |
Member
Author
|
The RHCOs ci failures look unrelated to this change.
/override ci/prow/rhcos
…On Fri, Jan 16, 2026, at 03:33, openshift-ci[bot] wrote:
*openshift-ci[bot]* left a comment (coreos/coreos-assembler#4410) <#4410 (comment)>
@dustymabe <https://github.com/dustymabe>: The following test *failed*, say `/retest` to rerun all failed tests or `/retest-required` to rerun all mandatory failed tests:
Test name Commit Details Required Rerun command
ci/prow/rhcos 59fb249 link <https://prow.ci.openshift.org/view/gs/test-platform-results/pr-logs/pull/coreos_coreos-assembler/4410/pull-ci-coreos-coreos-assembler-main-rhcos/2012074700108206080> true `/test rhcos`
Full PR test history <https://prow.ci.openshift.org/pr-history?org=coreos&repo=coreos-assembler&pr=4410>. Your PR dashboard <https://prow.ci.openshift.org/pr?query=is:pr+state:open+author:dustymabe>.
Details
Instructions for interacting with me using PR comments are available here <https://git.k8s.io/community/contributors/guide/pull-requests.md>. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow <https://github.com/kubernetes-sigs/prow/issues/new?title=Prow%20issue:> repository. I understand the commands that are listed here <https://go.k8s.io/bot-commands>.
—
Reply to this email directly, view it on GitHub <#4410 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABCR63QAZLVY3TNWSURD2WD4HCO6VAVCNFSM6AAAAACRGEVGIKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTONJYG43DKMJWG4>.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
|
@dustymabe: Overrode contexts on behalf of dustymabe: ci/prow/rhcos DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Allow group write permissions on /usr/bin because in upstream project's CI we want to overwrite binaries for testing. The dir is owned by root:root and CI runs in openshift as a user that is a member of the
root(GID: 0) group.See coreos/coreos-installer#1716